近年來，隨著軟體產業專業愈深，分工愈細，導致軟體業的工種不斷增加：工程師有前端、後端工程師、資料庫工程師、測試工程師，設計師有 UX 、UI、互動等不同設計師，管理師有專案經理、產品經理、數據分析師、行銷經理等，是不是 老花眼 眼花繚亂？

在 Scrum 的框架中，並沒有分的這麼細，一個 Scrum 團隊的角色只有三種： Product Owner、Scrum Master、Development Team，這三種角色是命運共同體。

你可能會問，每次遇到的並非全能型團隊，那如果有需要特殊的能力，是 Scrum 團隊中缺乏的怎麼辦？ Rson 所在的公司採取的是引入 Function Team 的成員支援，但他們不會是全職投入（用 RPG 遊戲比喻，有點像是某些特定的時期會有特殊技能的 NPC 夥伴加入，一旦該任務完成，該 NPC 夥伴就會離隊，只有主角們所處的「Scrum」團隊會一直「命運共同體」前進直到遊戲結束）

接下來，我們討論 Scrum 團隊中僅有的三種角色。

一、產品負責人（Product Owner）

Product Owner ，簡稱 PO。類似 PM ，產品的負責人，決定產品價值、方向的角色，整合各方意見、使用者回饋，以及與關係人斡旋，通常需要良好的溝通能力和協調能力。

Product Owner 主要負責項目：

1. 掌握產品 Roadmap，整合各方意見，平衡理想與現實。
2. 代表業務、客戶、使用者。
3. 維護、決定 Product Backlog （產品待辦清單）中的項目及 Story 的驗收標準。
4. 根據商業價值，決定產品待辦清單的排序，協助開發團隊產出有價值的成果。
5. 讓開發團隊能夠清楚了解 Product Backlog ，當需要的時候能夠向團隊解釋說明。

二、Scrum Master

Scrum Master ，簡稱 SM (疑？格雷不可以色色！！)，他是開發團隊的教練，確保正確導入 Scrum，協助產品負責人與開發團隊產出最大價值。一般來說，這個角色也經常會是組織中 Scrum 的傳教者，讓團隊中每個人了解 Scrum 的觀念、規則及實際運作方式。

Scrum Master 主要負責項目：

1. 確保團隊中每一位成員都足夠了解 Scrum。
2. 正確地帶領團隊運行 Scrum 開發方法。
3. 和 PO 一起確保開發團隊能夠理解 Product Backlog。
4. 主持與引導 Scrum 的各種活動／會議，例如 Daily Stand-up、Sprint Plan、Sprint Review、Sprint Retrospective 等會議。
5. 移除開發團隊在開發過程中遇到的阻礙，以及當有需要時，尋找並引入資源。

三、開發團隊（Development Team）

Dev. Team，簡稱 Team，為一跨職能開發團隊，通常混合著前端、後端、iOS、Android 等工程師。較成熟的團隊也許會編制專屬 UX／UI 設計師、成長駭客等。這個開發團隊的組成，打個比方來說，最好是一支跨軍種、擁有多重技能的「特遣部隊」，他們是為了產品（或目標）的成敗而建置。當然，所挑選的團隊成員，應該要具備完成每個 Sprint 功能增量 （Increments）所需的專業技能。例如一個以遊戲 APP 為產品的團隊，就會需要具備開發 Android／iOS 及互動設計能力的團隊成員。

註：實務上的經驗來看，Rson 目前待的公司，本質上屬於矩陣型組織，但由於所在單位奉行敏捷，所以當有一個新的專案或產品要啟始時，就會從單位內矩陣組織中尋找適合的人選，組成一隻以目標為導向（Taskforce）的敏捷開發團隊，一但任務完成，才會各自散回到原本的隊伍，等待下一個產品／專案啟動。

Development Team 主要負責項目：

1. 將 Sprint Backlog 中的 Story 拆解為可執行的工項，並進行估點。
2. 承諾與完成該次 Sprint 的開發工項。
3. 維持好每次 Sprint 開發的品質，讓程式碼能夠盡可能向下相容。（若每次的 Sprint 增量要發布到 Prodution 環境時，PO 及 Scrum Master 都得提心吊膽，擔心舊的用戶可能 Crash 或出現不該出現的 issue，這樣的話不是很健康，也會有斷崖式流失用戶的風險）。

上述三種角色，是 Scrum 裡做事的人，其他與專案／產品相關，但沒有實際參與的角色，統稱為利害關係人 （Stakeholder），例如客戶、使用者、單位主管、外部顧問等。一般而言 Stakeholder 只能觀察並給予意見，不能干擾開發過程及決策。當然，這是 Scrum 的理想，實際運行上非常之難難難（PO／SM 們委屈貌）。

明天，我們接著這個議題。